【レポート】知る・創る・繋ぐ『ゼルダの伝説　ティアーズ オブ ザ キングダム』で再構築した開発環境とサウンド制作事例 #CEDEC2024 #classmethod_game

こんにちは、ゲームソリューション部の入井です。
今回はCEDEC2024で聴講したセッション『知る・創る・繋ぐ『ゼルダの伝説　ティアーズ オブ ザ キングダム』で再構築した開発環境とサウンド制作事例』についてレポートします。

セッション概要

『ゼルダの伝説　ティアーズ オブ ザ キングダム』では、前作『ゼルダの伝説　ブレス オブ ザ ワイルド』と比べてゲーム内の要素が増加し、ウルトラハンドやスクラビルドなどのゲーム仕様によって要素間の結びつきが強くなり、複雑性が大幅に増加しました。
その状況を乗り越えるべく、前作の経験を活かしながらランタイムシステムを刷新し、合わせて開発環境も再構築しています。

本セッションでは、新しくなった開発環境を、「ゼルダの伝説」シリーズの開発スタイルや、サウンドチームの事例などを交えながら紹介します。ゲームの制作過程において後工程になりがちなセクションであっても、開発環境を上手く使ってコンテンツを作り上げた事例が、何かの参考になれば幸いです。

※CEDEC2024セッションページより引用

印象に残った点

より良いアイディアのためのフラットな開発体制

近年のゲーム開発では、規模の拡大や仕様の複雑化が進み、以前は一人で担当していた部分が分業化されることが多くなりました。例えば、前作『ゼルダの伝説　ブレス オブ ザ ワイルド（以下、BotW）』の時点で、敵キャラ1体を制作するために十数名のスタッフが関わる必要があったとのことです。

このような場合、リードプログラマーなどの限られたリーダーが仕様を考え、下の人間に作業として割り当てる縦割り構造がよく取り入れられます。しかし今回の開発では、リーダーポジションの人員は作りつつも、より良いアイディアが出せるようにエンジニアやアーディスト、コンポーザーなどがポジションを問わずに意見を出し合うフラットな開発体制を重視したとのことです。

『知る』ためのデータドリブンな仕組み

フラットな体制でそれぞれのポジションのスタッフ一人一人が良いものを作るには、スタッフ全員が仕様を十分に知ることが必要となります。
仕様を知るためには仕様書やドキュメントが使われることが多いですが、開発が進むにつれ次々と変わるゲームの実体にこれらの資料が追従できず、結果的に誤った情報を受け取ってしまうということがよく起こります。

そこで、BotW開発の際にデータドリブンな体制の構築が推し進められました。これにより、挙動やパラメータをデータで実装する形になり、仕様書で管理する範囲が縮小化されました。

データはグラフやツールなどで様々な角度から可視化が可能です。このデータに加えて実際のゲームの手触りを組み合わせることで、ゲームの最新の情報を知ることが可能な動く仕様書となります。

任天堂では独立した様々なツール群を利用

Unreal Engineなどの汎用ゲームエンジンのように、1つのフレームワークを土台に様々なツールが作成される統合型の実装形態に対し、任天堂ではそれぞれのツールが独立した形態（セッションではコンポーネント型と呼称）を採用しているとのことでした。

ゲームの挙動、グラフィック、UIなど分野ごとに数多くのツールを任天堂全体で保持しており、その中からプロジェクトごとに必要なものを選択して開発に利用しているとのことです。

それぞれのツールが独立しているメリットとして、様々なゲームデザインに対応できたり、統合型のような開発上のルールが無いので新しく開発しやすい、新技術を試しやすいというものがあります。

一方で、ツール間の連携が弱かったり、ツールを通してゲーム全体の構造を俯瞰することが難しいという課題があります。

今作『ゼルダの伝説 ティアーズ オブ ザ キングダム（以下、TotK）』では、前作BotWよりも仕様の複雑化が進んだ結果、これらの課題が無視できなくなりました。

『LocalDB』による開発ツール同士の連携

ツール間の連携が弱いという課題の対策として作られたのが、それぞれのツールが参照する共通基盤となるデータベースです。

このデータベースには3Dモデルのボーン情報などの細かいパラメータ等の他、3Dモデルやイベントデータ、BGMデータ、各種DCGツールのデータ、ソースコードなどプロジェクトで使われるあらゆるファイルまで可能な限り載せられるようになっています。

ただし、1つのデータベースを共有する形では、同じファイルを複数の開発者が同時編集した場合などにコンフリクトが発生します。そこで、各開発者のツールが参照するのは、各開発者のローカルPC上に作られたデータベース上のデータにする仕組みになりました。このデータベースはローカル上に存在することから『LocalDB』という名称にしたとのことです。

もちろん、LocalDBだけでは他の人の所持するデータを参照したい場合に困るので、それを補うためのデータベースがサーバー上にも用意されています。こちらはグローバルに使われることから『GlobalDB』という名称にしたとのことです。

この仕組みを構築したことによりツール間で同じデータを共用する形となり、例えばMayaでボーンの名称を変更するとそれがそのままDBに反映され、他のツールでボーンの名称を参照した時も変更後の名称が反映されるようになりました。

『ProjectPortal』によるゲーム構造の可視化

続いて、ゲーム全体の構造を俯瞰することが難しいという課題の対策として作られたのが、LocalDBのデータを元に全体構造を可視化する『ProjectPortal』というツールです。

これは、任意のデータをキーワードやタグなどで絞り込んだり、そのデータの繋がりを辿ってデータ同士の関係性を把握したりできるツールです。

例えば、タグを使うことで特定の特性を持つアイテム情報を取得したりすることができます。

単純なタグ機能だけでは人力で作成するのが大変なため、任意のSQLクエリをタグ化できるクエリタグという機能も用意したとのことです。

また、宝箱の位置情報とともにその中身のアイテム情報も結合してリストアップする、といったことも可能です。

サウンドの現場での活用事例

LocalDBとProjectPortalが実際の開発でどのように活用されたかの実例として、サウンドチームでの活用事例が紹介されました。

その中の一つ、『ゲルドの街防衛戦』というゲーム中イベントのサウンド演出制作の例では、状況の変化に応じてBGMが変わっていく演出をどのように作ったかが紹介されました。

インタラクティブな音楽演出を効果的にするには、曲を切り替えるタイミングやフェードの時間などを細かく設定する必要があります。例えば、どの台詞が表示されたタイミングで戦闘BGMを開始するか、というような内容です。

このような演出内容を検討するには、イベントシーンの仕様を細かく把握する必要があり、それに役立つのがProjectPoratlです。

ProjectPortalを使えば、どのBGMがどのイベントシーンで使用されているのかを繋がりをたどることができます。そして、そのまま対象のイベントデータをツールで開くことで、イベントの内容の細かな部分まで把握することができます。

基本的にイベントデータはゲームデザイナーが編集するものですが、必要に応じてサウンド担当が直接編集することも珍しくなかったとのことです。

感想

TotKはかなり面白く遊んだ一方で複雑な土台のシステムや手の込んだ演出などから開発体制が気になっていたので、セッション全体を面白く聞くことができました。

セッション中ではLocalDBの仕組みは簡単な説明で終わりましたが、GlobalDBにデータを書き込むトリガーや、コンフリクトなくデータを保管する仕組みはどのように実現しているのか気になりました。また、膨大なデータを開発メンバー全員が共有していると、GlobalDBやネットワークへの負担がかなり高くなりそうで、そういった課題もどのように解決したのか気になりました。このあたり、今後別の講演等で深掘りがあったら是非聞いてみたいと思いました。

開発規模が大きくなるにつれて、組織の縦割り構造は避けられなくなると思うのですが、それでも良いアイディアを出すためにフラットな開発体制へこだわり、それを維持するためにLocalDBやProjectPortalという仕組みを作る熱意から、任天堂のものづくりの思想が感じられました。